DevOps Overview BTech CSE Sem V · UPES Dehradun
Unit I · Lecture 4

Agile Manifesto, Part 1
Individuals & Interactions · Working Software

A deep dive into the first two values of the Agile Manifesto —
what they mean, why they matter, and how to apply them.

COURSE
DevOps Overview
UNIT
I of IV
LECTURE
4 of series
PREV. LECTURE
Agile vs Waterfall

Dr. Mohsin Furkh Dar  ·  School of Computer Science, UPES Dehradun

Overview

What We Cover Today

🔁 Recap
Quick recap of the four Agile values and how iterative Agile cycles work.
🧑‍🤝‍🧑 Value 1: Individuals & Interactions
Why people and conversations matter more than rigid processes and tooling.
🗣️ Communication Structures
Face-to-face communication, co-located teams, and the cost of indirect channels.
🧩 Self-Organising Teams
What it means for a team to organise itself — and why it produces better designs.
🚀 Value 2: Working Software
Why running, tested code is the only real measure of progress.
📄 Just Enough Documentation
Documentation is not eliminated — it's right-sized to serve the team and the product.
Recap — Lecture 3

Where We Left Off

Agile is both iterative (refine what exists) and incremental (deliver new working functionality). Each sprint runs through planning, daily standups, development & testing, review, and retrospective — inverting the risk curve compared to Waterfall.
The Agile Manifesto (2001) expresses this philosophy as four value statements, each contrasting something Agile prioritises with something it values less (but does not discard):
①②
Today's focus
Individuals & interactions over processes & tools and working software over comprehensive documentation — the two "how we build" values.
③④
Next lecture
Customer collaboration over contract negotiation, and responding to change over following a plan — the two "how we relate to the customer" values.
01

Individuals & Interactions

Individuals and interactions over processes and tools
Value 1 — Origins

Why "People First" Became a Core Value

Heavyweight processes promise predictability by making work independent of who does it. In practice, this often produced rigid workflows where people followed steps without understanding why — and problems that needed a conversation instead got routed through forms, tickets, and approval chains.
  • The trap of process-first thinking: When something goes wrong, the instinct is to add a new process step or tool to prevent recurrence — over time, this accumulates into bureaucracy that slows everyone down.
  • Tools cannot replace judgment: A project management tool can track tasks, but it cannot resolve ambiguity, negotiate trade-offs, or notice that a requirement doesn't make sense — only people can.
  • The Manifesto's claim: Skilled, motivated people, given the right environment and support, will find better solutions than any process can prescribe — and they will adapt that process when it stops serving them.
  • Important nuance: Processes and tools still matter — version control, CI pipelines, issue trackers are valuable. The point is they should serve people, not constrain or replace human judgment and communication.
Value 1 — In Practice

Communication: Direct vs Mediated

📋 Process-Heavy Communication

Dev
📄
Lead
Lead
📄
PM
PM
📄
Client
  • Questions answered via formal change requests
  • Decisions take days — wait for the right meeting
  • Information degrades with each handoff (telephone effect)
  • Tickets/emails create paper trails but slow resolution

💬 Agile Direct Communication

Dev
Lead
⬤
PM
Client
All connected — same room, same standup, same chat channel
  • Questions answered in minutes via direct conversation
  • Decisions made by the people closest to the problem
  • Shared context — less information loss
  • Whiteboard/diagram in 5 minutes > week-long spec document
Value 1 — Self-Organising Teams

Why Teams Organise Themselves

Command-and-Control Model

  • Manager assigns tasks to individuals
  • Work is divided before anyone understands the full problem
  • Specialists work in isolation, integration happens late
  • Decisions flow top-down; feedback flows slowly upward
  • Team members optimise for "my part," not the whole

Self-Organising Model

  • Team collectively decides who does what, and how
  • Work divided after the team understands the goal together
  • Cross-functional collaboration — pairing, mobbing, shared reviews
  • Decisions made by whoever is closest to the information
  • Team members optimise for the sprint goal as a shared outcome
From the 12 Principles: "The best architectures, requirements, and designs emerge from self-organising teams." This is an empirical claim — teams with autonomy and ownership consistently produce more coherent solutions than those following externally imposed task breakdowns.
Value 1 — Supporting People

"Give Them the Environment and Support They Need"

🏢 Co-location / Virtual equivalents
Shared physical or virtual space (video-always-on, shared channels) reduces friction in spontaneous conversation.
🛡️ Psychological safety
People raise problems, admit mistakes, and ask "naive" questions without fear of blame — essential for early feedback.
🎯 Clarity of goal, not task
Teams given a "why" and a goal — not a prescriptive task list — can find better paths to the outcome.
🔧 Access to tools, not gatekeeping
Developers empowered to provision environments, run pipelines, and make technical decisions without lengthy approvals.
⏳ Protected focus time
Minimise context-switching and interruption-driven work — sustainable pace requires uninterrupted blocks of deep work.
🤝 Trust over surveillance
Managers trust teams to deliver and support them — rather than micromanaging through status reports and check-ins.
02

Working Software

Working software over comprehensive documentation
Value 2 — Origins

Documentation as a Proxy for Progress — and Its Failure

In Waterfall-era projects, completing a requirements document or design specification was treated as "progress" — even though no software existed yet. Teams could be 80% through the schedule and 0% through anything a user could actually run.
  • Documents can be wrong and still "complete": A 200-page SRS can be internally consistent, fully reviewed, and signed off — and still describe a system nobody wants. Completeness ≠ correctness.
  • Documentation goes stale fast: The moment code diverges from the design document (which happens almost immediately), the document becomes actively misleading rather than merely incomplete.
  • Working software is falsifiable: You cannot "fake" a feature that actually runs, handles edge cases, and produces correct output. It is the one artifact that cannot lie about its own state.
  • Manifesto's claim: The primary measure of progress should be: can a user run this and get value from it right now? Everything else is a proxy — sometimes useful, but never a substitute.
Value 2 — Definition of Done

What Actually Counts as "Working Software"?

"It compiles" is not working software. "It runs on my machine" is not working software. The Definition of Done (DoD) is the team's shared, explicit checklist for what "working" actually means.
✓
Code written and peer-reviewed — meets the team's coding standards, reviewed by at least one other developer
✓
Automated tests written and passing — unit tests at minimum; integration tests where applicable
✓
Integrated into the main codebase — merged, builds successfully, no broken dependencies
✓
Deployed to a test/staging environment — runs in an environment resembling production, not just a developer laptop
✓
Meets acceptance criteria — satisfies the conditions defined with the Product Owner for this user story
✓
Demonstrable to stakeholders — can be shown working end-to-end in the sprint review
Value 2 — Documentation Reframed

"Comprehensive" Doesn't Mean "None"

A common misconception: Agile teams write no documentation. In reality, Agile asks: "Does this document help someone do their job better?" If yes, write it — concisely. If it exists mainly to satisfy a process checkbox, question it.
Document TypeComprehensive (Waterfall-style)Agile "Just Enough"
Requirements 200-page SRS, frozen before coding begins User stories with acceptance criteria — living backlog
Design Detailed UML for every class before implementation Lightweight architecture diagrams; details emerge in code
Code documentation Separate manuals describing every function Self-documenting code, inline comments where needed, README
Test plans Exhaustive manual test scripts for every scenario Automated test suites that double as living specifications
Status reporting Weekly written status reports up the chain Visible Burndown charts, working demo at sprint review
Putting It Together

Scenario: A New Feature Request Arrives

📋 Process-Heavy Response

  • Request logged as a formal Change Request (CR-2231)
  • CR routed to Business Analyst for impact analysis
  • BA drafts updated requirements document — 2 weeks
  • Document circulated for review and sign-off — 1 week
  • Design document updated to reflect new requirement — 1 week
  • Only now does development begin
  • Total time to first line of code: ~4 weeks
  • If the request was based on a misunderstanding, this is discovered only after coding starts

💬 People + Working Software Response

  • Product Owner discusses the request directly with the requester — same day
  • Team huddles for 15 minutes — clarifies intent, sketches approach on a whiteboard
  • Written as a user story with acceptance criteria — 30 minutes
  • Added to the backlog; prioritised for the next sprint
  • Working prototype demoed within the sprint — 1–2 weeks
  • Requester sees real software, gives immediate feedback
  • Misunderstandings caught in days, not after weeks of paperwork
Clearing Up Confusion

Common Misconceptions About These Values

❌ "Agile means no process"

  • Agile teams use Git, CI/CD, issue trackers, code review tools daily
  • The value is about priority, not absence — people and conversation come first when process and conversation conflict

❌ "Agile means no documentation"

  • READMEs, API docs, architecture diagrams, runbooks all still exist
  • The difference: documentation is written because it's useful, not because a phase gate requires it

✅ "Individuals & interactions" means…

  • When a tool or process gets in the way of solving the problem, the team has permission to talk it through and adapt
  • Trust people closest to the work to make good decisions

✅ "Working software" means…

  • The best evidence of progress is something a user can interact with
  • Documentation supports working software — it does not substitute for it
Lecture Wrap-Up

Key Takeaways & What's Next

💡
People over process
Processes and tools support people — they should never replace conversation, judgment, and direct problem-solving between team members.
💡
Self-organisation works
Teams given a clear goal, autonomy, and the right environment produce better architectures and designs than externally-dictated task breakdowns.
💡
Working software is truth
Documents can be complete and wrong. Running, tested software is the one artifact that cannot fake its own correctness — it is the real measure of progress.
💡
Definition of Done
"Working" is defined explicitly by the team: coded, reviewed, tested, integrated, deployed to staging, and demonstrable — not just "compiles."
💡
Not "zero process/docs"
Both values are about priority under conflict, not elimination. Agile teams still use tools and write documentation — just only what genuinely serves the work.
➡️
Next lecture
The remaining two Agile values: customer collaboration over contract negotiation, and responding to change over following a plan.
DevOps Overview · Unit I · Lecture 4  ·  Dr. Mohsin Furkh Dar  ·  UPES Dehradun · Summer 2026
← → or swipe